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ABSTRACT 


In  this  paper  we  discuss  the  key  issues  in  the  generation 
and  distribution  of  messages  in  a computer  network.  The  princi 
pal  issues  are:  user  support,  privacy  and  security,  addressing 
and  standards  and  regulations.  Examples  of  current  message  sys 
terns  on  the  ARPANET  are  discussed. -w 


1.  INTRODUCTION 


In  this  paper  we  discuss  some  key  issues  dealing  with  net- 
work message  services  [l],  [2].  A network  message  is  a record 
in  a file  that  is  transported  from  one  file  to  another.  The 
sending  and  receiving  files  can  be  in  the  same  computer  or  in 
other  computers  in  the  network.  When  user  1 sends  a message  to 
user  2,  the  actual  mechanism  corresponds  to  a record  in  user  l's 
message  file  being  sent  to  user  2's  message  file.  User  2 does 
not  have  to  be  logged  in  when  the  message  is  actually  sent.  It 
is  sent  to  his  message  file  which  is  like  a mailbox,  and  can  be 
retrieved  at  any  later  time.  Thus  the  sender  is  decoupled  from 
the  receiver.  A network  message  service  thus  provides  record 
communication  in  an  electronic  medium  and  can  be  thought  of  as 
electronic  mail. 


Computer-based  message  services  are  not  new.  Indeed,  such 
services  as  TWX  and  TELEX  have  been  in  existence  for  a number  of 
years.  Since  1972,  ARPANET  users  have  been  using  message  ser- 
vices of  increasing  sophistication  and  over  the  years,  network 
messages  have  grown  to  become  the  largest  single  source  of  traffic 
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Ur.  .«).  -v  ..  on  the  ARPANET.  In  this  paper  we  will  discuss  the  features  of 
the  store  commonly  used  network  message  services  on  ARPANET  and 
> discuss  some  key  issues  in  the  development  of  message  services 

i for  s computer  network. 

j ! 

! 2.  FEATURES  OF  NETWORK  MESSAGE  SERVICES 

i 

■ A network  message  system  is  a computer  program  that  has  two 

principal  parts:  1.  A message  handling  program  and  2.  a mes- 
sage distribution  program  or  mailer. 

The  message  handling  program  has  the  key  features  of  message 
composition,  reading  and  filing.  The  mailer  has  the  responsibil- 
ity of  delivering  the  message  to  the  receivers ' mailboxes . Many 
of  the  sophisticated  message  handling  systems  available  in  ARPANET 
today  contain  text  processing,  editing,  and  formatting  features  to 
assist  in  the  composition  of  messages.  They  usually  provide  a 
flexible  file  management  structure  so  that  messages  can  be  stored 
in  a user-generated  data-base  and  manipulated  using  standard  data 
management  techniques  of  sorting,  searching,  retrieving  and  arch- 
iving . 
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3.  MESSAGE  STRUCTURE 


A message  has  two  parts:  a header  and  the  text  itself.  The 
header  has  a number  of  fields  which  include  such  information  as 
the  sender,  the  primary  recipient (s) , the  recipients  for  copies, 
the  date  and  time  the  message  was  sent  and  the  subject  of  the 
message.  In  a computer  network  the  header  and  addressing  format 
must  be  standardized  in  order  for  different  computers,  operating 
systems,  and  message  handling  systems  to  recognize  and  process 
the  Incoming  and  outgoing  messages.  In  the  ARPANET  the  header  of 
. a received  message  has  a format  as  in  the  following  example: 

• 

Mail  from  BBN-TENEXE  rcvd  at  29-Jun-78  0938-PDT 
Date:  29  Jun  1978  1236-EDT 

From:  BINDER  at  BBN-TENEXE  - - — 

Subject:  Re:  IEEE  Satellite  paper 

To:  KUO  at  USC-ISI  

CC:  BINDER 


An  outgoing  message  using  the  SNDMSG  command  on  ARPANET/TENEX  Sys- 
tems has  the  following  format: 


Catch  l in . / \'o*' t r • 


SNDMSG  (CR) 

To:  < Mailbox  name  > at  < Computer  name  > (CR) 
->l  CC:  < Mailbox  name  > at  < Computer  name  > (CR) 
j ■ Subject:  Miscellaneous  (CR)  


i 

i 


! 
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* 
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>ii i>1  running  head  — *•  > i 1 T 

l.«i  Jin.  ' j to::  , Message  (?  For  Help): 

where  (CR)  means  carriage  return.  The  headers  To,  CC,  Subject 
and  Message  are  prompt  symbols  and  are  typed  by  the  computer. 

The  sender  merely  enters  the  requested  information  in  the  header 
fields  followed  by  a (CR)  to  enter  the  next  field.  After  he  com- 
pletes typing  the  message  text  he  types  a (control)  Z and  a car- 
riage return,  then  the  mailer  indicates  that  the  message  has  been 
delivered  with  a statement  of  the  following  kind: 

Kuo  at  USC-ISI — OK 
BINDER— OK 


i 


If  the  machine  to  which  the  message  is  addressed  is  unable  to  ac- 
cept the  message  then  a statement  of  the  following  kind  appears: 

ROTHNIE  at  CCA— QUEUED— TIMED-OUT 

The  message  is  then  stored  in  a buffer  until  the  addressee  (ma- 
chine) is  able  to  accept  the  message.  If,  for  the  previous  ex- 
ample, ROTHNIE  does  not  have  a mailbox  at  CCA  then  the  mailer 
prints  a statement  to  the  sender  or  sends  a msg  to  the  sender  to 
explain  why  it  was  unable  to  deliver  the  message. 

Certain  sites  have  multiple  computers  on  ARPANET.  Examples 
are  BBN  with  five  TENEX  systems  labeled  BBNA,  B,  C,  D,  E.  Any 
message  addressed  to  any  BBN  machine  will  be  correctly  forwarded 
to  a user  on  any  other  BBN  machine.  This  forwarding  capability, 
however,  is  quite  rudimentary  and  exists  only  on  certain  sites  in 
ARPANET.  In  a later  section  we  will  discuss  the  idea  of  central- 
ized address  data  bases  and  directories. 


4.  HERMES,  MSG,  AND  SIGMA 

HERMES . HERMES  [3]  is  a message  processing  system  developed  by 
Bolt  Beranek  and  Newman,  Inc.  (BBN)  as  a message  communication 
•yatem  for  certain  TENEX  operating  systems  on  ARPANET.  HERMES  is 
now  operating  at  eight  ARPANET  TENEX  sites  and  is  also  accessible 
on  the  US  public  packet  network,  TELENET. 

HERMES  has  the  following  basic  capabilities: 

1.  Message  Composition 

2.  Message  Reading 

I 

3.  Message  Filing 


4.  Measaae  Searchina 
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S.  Message  Deleting 

It  has  special  features  of  message  file  management.  Messages 
can  be  stored  In  message  files  and  the  messages  within  a file  can 
be  organized  into  permanent  sequences , which  can  be  referred  to 
by  name.  Sequences  can  be  sorted,  edited,  and  changed  by  simple 
commands.  Other  advanced  features  of  HERMES  include  selecting 
messages  by  naming  the  characteristics  desired  and  creating  per- 
manent, named  collections  of  such  message  characteristics  known 
as  filters.  Once  created,  these  filters  can  be  used  to  build  up 
or  narrow  down  selections  of  messages  in  a long  message  file. 
HERMES  also  allows  the  creation  of  special  templates  in  order  to 
tailor  input/output  message  formats.  In  addition  to  these  special 
features,  HERMES  has  an  interactive,  on-line  guide  to  special 
features  and  commands  and  extensive  on-line  reference  material. 
HERMES  is  flexible  and  easy  to  use  and  is  currently  one  of  the 
moat  widely  used  message  systems  on  ARPANET  today. 


MSG.  Another  extensively  used  message  processing  system  supported 
by  the  TENEX  systems  on  ARPANET  is  program  MSG  [4]  developed  by 
the  Information  Sciences  Institute  of  the  University  of  Southern 
California  (USC/ISI).  The  commands  in  MSG  are  single  characters 
and  are  self-completing.  A complete  set  of  MSG  commands  is  given 
In  Table  1.  Most  are  self-explanatory.  The  message  reading  in- 
structions are 


H Headers  (message  sequence): 

T Type  (message  sequence): 

Typing  H would  yield  a typical  list  as: 


65  28Jun  BINDER  at  BBN-TENEXE  RE:  IEEE  Satellite 

66  29Jun  MURPHY  at  USC-ISIE  CCISW  attendee  list 

67  29Jun  SACERDOTI  at  SF.I  CCIS  Workshop 

68  . 30Jun  To:  SACERDOTI  at  SRI  RE:  CCIS  Workshop 


Paper 


The  Header  fields  are: 

< MSG  NO.  > < DATE  > < SENDER  OR  RECEIVER  > < SUBJECT  > 


If  the  instruction  I is  typed,  the  length  of  the  message 
acters  la  alao  Included  in  the  header  field. 


in  char- 


The  send  message  instructions  are: 

S SNDMSG  (CONFIRM) : 

A Answer  Message  Number: 

, F Forward  (message  sequence): 


C.uchl  LiuWccirvwl  ‘ 
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1 , The  file  Instructions  are: 


M Move  (message  sequence): 

Into  File  name: 

R Read  File  name: 

0 Overwrite  old  file: 

i I 

» 

The  delete  instructions  are: 


D Delete  (message  sequence) : 

U Undelete  (message  sequence): 

Because  MSG  uses  extensive  string  searches  and  file  manipulations, 
certain  instructions  tend  to  require  high  processor  overhead.  One 
generally  finds  that  the  more  sophisticated  and  easy  to  use  a sys- 
tem is,  the  more  memory  and  greater  processing  time  it  requires. 

SIGMA.  US  military  record  traffic  is  usually  sent  by  AUTODIN  1, 
a atore-and-forward  message  switching  network  of  the  US  Depart- 
ment of  Defense.  The  Military  Message  Experiment  (MME)  is  an 
experiment  currently  being  carried  out  at  the  Headquarters  of  the 
Commander-in-Chief,  Pacific  in  Honolulu,  Hawaii  for  the  automated 
distribution  of  AUTODIN  message  among  military  users  in  a command 
center.  The  message  processing  computer  for  MME  is  a PDP-10  TENEX 
time-sharing  system  which  is  connected  to  the  AUTODIN  system  vnot 
ARPANET).  The  MME  message  processing  system  SLGMA  [5],  which  is 
being  developed  by  the  Information  Sciences  Institute  of  the  Uni- 
versity of  Southern  California,  is  constructed  around  a global 
database  of  AUTODIN  messages.  Users  can  create  their  own  message 
files  from  this  global  database.  Outgoing  messages  can  be  com- 
posed, edited,  reviewed,  and  released  using  completely  automated 
procedures.  Storage,  organization  and  retrieval  of  incoming  mes- 
sages are  among  a long  list  of  SIGMA's  automated  features.  SIGMA 
Is  an  example  of  a centralized  message  processing  system  which 
acts  as  a distributor  of  messages.  It  was  developed  for  a non- 
computer  specialist  military  user  and  thus  has  a greater  range  of 
user-assist  and  prompt  features  than  HERMES  or  MSG.  Since  it 
operates  in  a military  milieu,  SIGMA  provides  security  features 
which  are  absent  in  other  non-military  message  handling  systems. 
SIGMA  allows  four  levels  of  security:  TOP  SECRET,  SECRET,  CONFI- 
DENTIAL AND  UNCLASSIFIED.  In  addition,  SIGMA  contains  a number 
of  automated  protection  mechanisms  to  insure  that  correct  security 
procedures  are  carried  out. 


Because  of  its  large  number  of  user-support  and  security  fea- 
tures, SIGMA  is  necessarily  complex.  The  price  of  complexity  In 
this  case  is  slow  response.  This  is  one  of  the  key  issues  that 
must  be  considered  in  the  design  of  an  automated  message  handling 
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1st  Liu.'  ; . , " 5.  DESIGN  ISSUES  FOR  NETWORK  MESSAGE  SERVICES 

User  Support  Features.  Over  the  past  few  years,  the  ARPANET  mes- 
sage services  have  become  quite  sophisticated  in  their  user-support 
features  - prompting,  editing,  message  composition,  filing  and 
retrieval.  A message  system  such  as  HERMES  or  MSG  requires  sub- 
stantially more  memory  than  a simple  system  that  only  reads  mail 
from  a message  file.  In  SIGMA,  not  only  are  there  extensive  user- 
support  features  but  also  security  and  protection  features.  At 
the  time  of  this  writing  ten  simultaneous  SIGMA  users  can  place  a 
substantial  load  on  the  TENEX  time-sharing  system,  with  the  result 
that  the  time  required  to  display  a single  message  of  file  on  a 
user  terminal  CRT  screen  is  on  the  order  of  a minute  or  more.  In 
the  case  of  SIGMA,  there  seems  to  be  a direct  relationship  between 
the  degree  of  user  support  and  response  time. 

For  a time-sharing  system  in  which  the  message  handling  pro- 
grams are  not  re-entrant,  each  cn-line  message  system  user  must 
have  his  own  copy  of  the  program  in  memory  which  places  a heavy 
demand  on  available  on-line  memory  to  service  message  users.  On- 
line file  space  is  another  valuable  resource  to  message  users.  In 
a system  like  BBN-TENEX,  a user  is  allocated  only  a given  number 
of  pages  of  memory.  He  is  not  allowed  to  exceed  his  page  alloca- 
tion. This  limitation  of  on-line  memory  places  a practical  con- 
straint on  user  file  space;  so  that,  in  spite  of  the  sophisticated 
file  manipulative  mechanisms  available-  in  a system  like  HERMES, 
conservation  of  file  space  often  place  severe  limitations  on  their 
use. 


Designers  of  message  systems  must  design  for  their  intended 
users'.  If  the  user  community  consists  of  experienced  computer 
users  then  the  message  processing  system  can  be  quite  rudimentary 
since  the  users  can  use  text  editors  and  file  management  systems 
that  are  not  an  integral  part  of  the  message  handling  system  to 
compose,  read,  and  file  their  messages.  On  the  other  hand,  if 
the  intended  user  is  a non-specialist,  like  a military  user,  then 
the  message  handling  system  must  contain  many  more  user  support 
features,  such  as  prompts  and  on-line  instructions  which  tend  to 
load  down  the  sytem  and  make  the  system  response  time  slower. 


Privacy  and  Security.  ARPANET  messages  are  records  or  files  which 
are  addressed  as  mailboxes.  It  is  important  to  safeguard  the  pri- 
vacy of  the  message  files.  Since  time-sharing  system  users  all 
have  passwords  to  access  their  files,  protection  of  the  messages 
is  afforded  to  the  degree  in  which  the  password  system  is  secure. 
It  would  be  quite  difficult  but  not  impossible  for  a user  to  send 
a message  under  an  assumed  name  in  the  current  ARPANET  message 
systems.  There  is  no  protection  currently  if  a number  of  users 
I share  one  account  and  password.  True  security  is  obtainable  only 
when  a provably  secure  operating  system  can  be  developed.  Until 

1 M ful. 
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that  time,  standard  protection  methods  for  accounts  and  files  can 
be  used  to  protect  message  files. 

Another  security-related  issue  is  that  the  mailer  must  be 
sufficiently  reliable  to  ensure  that  messages  are  delivered  only 
to  intended  recipients  and  not  misdelivered.  Within  the  ARPANET 
the  ARPA  file  transfer  protocol  (FTP),  which  has  heretofore  been 
highly  reliable,  is  used  for  the  delivery  of  mail.  However,  on 
rare  occasions  messages  have  been  misdelivered  or  lost.  In  such 
cases,  it  would  be  desirable  to  have  trace  mechanisms  to  establish 
some  degree  of  accountability.  Such  trace  mechanisms  are  hard  to 
develop,  but  are  desirable,  if  not  necessary. 


Addressing.  When  users  of  a central  time-sharing  system  send 
messages  to  each  other,  their  messages  require  only  a one-level 
address  - their  mailbox  names.  Network  messages  must  have  a two- 
level  address  in  the  form:  < mailbox  name  > at  < host  computer  >. 
If  a sender  knows  both  the  intended  recipient's  mailbox  and  the 
host  at  which  the  mailbox  resides,  then  the  message  can  be  deliv- 
ered by  the  mailer.  If  either  piece  of  information  is  missing, 
then  an  address  directory  must  be  consulted  to  obtain  this  infor- 
mation. The  ARPANET  community  currently  has  a published  directory 
for  this  purpose.  Known  as  the  ARPANET  DIRECTORY  [6],  it  is  is- 
sued once  a year  by  the  Network  Information  Center  of  SRI  Inter- 
national. There  is  no  on-line  data  base  anywhere  on  the  ARPANET 
that  contains  the  information  in  the  ARPANET  DIRECTORY.  Such  an 
on-line  data  base  is  desirable,  but  the  projected  cost  and  effort 
of  maintaining  such  a central  data  base  was  deemed  unnecessarily 
high  and  thus  the  task  was  not  supported.  Since  ARPANET  is  not  a 
public  network,  rudimentary  address  directories  are  perhaps  ade- 
quate for  most  users.  However  a public  network  message  service 
must  provide  better  directory  information  services.  With  recent 
advances  in  distributed  data  base  techniques  [?"],  it  is  now  poss- 
ible to  have  a distributed  network  information  directory,  in  which 
each  host  maintains  its  directory  of  mailbox  addresses  and  makes 
this  information  available  to  other  host  users.  When  internet 
messages  become  feasible  they  place  an  ever  greater  demand  on 
directory  information  services. 

An  orthogonal  requirement  to  providing  better  directory  in- 
formation services  is  that  of  protecting  the  privacy  of  the  users 
of  the  network.  If  a user  does  not  wish  to  send  or  receive  mes- 
sages, his  account  should  not  be  listed  in  the  directory.  Stan- 
' dards  must  be  agreed  upon  in  providing  inter-network  directory 

information  services. 

Standards  and  Regulations.  In  order  for  messages  to  be  passed 
from  one  computer  to  another,  message  formats  must  be  standard- 
' ized  in  terms  of  header  fields  and  text  fields.  If  there  is  to 
be  internetwork  communications  then  message  formats  must  be  stan- 
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In  the  international  TELEX  networks.  Standards  for  inter-packet 
•witching  network  messages  are  presently  not  available  and  are 
dependent  upon  standards  for  internet  protocols  such  as  X-2S. 
Different  countries  have  varying  regulations  concerning  network 
messages.  In  most  countries  network  messages  are  so  new  as  to 
have  escaped  scrutiny  by  postal  and  telecommunications  authorities. 
Thus  far,  computer  network  messages  in  the  US  are  regarded  as  a 
computer  service,  and  not  a telecommunications  service  and  thus 
has  not  come  under  FCC  (Federal  Communications  Commission)  juris- 
diction. How  many  other  countries  view  computer  network  message 
services  in  this  way  is  unknown.  The  author  believes  that  in  the 
next  five  or  ten  years  many  countries  will  face  up  to  the  issue 
of  electronic  mail  services.  In  that  context,  computer  network 
message  services  will  be  examined  carefully.  Detailed  regulations 
and  standards  will  then  be  established  for  internetwork  and  inter- 
national computer  message  services. 
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* Cmnd.  Char. 


Meaning 


Answer  message  number:  <Message-number>  _ 

Reply  to  whom  the  message  Is: 

F — From 

<Return>  — Same  as  F 
, T — To  list  plus  original  sender 

C — Cc  list  plus  to: 

List  plus  original  sender 
Backing  up  — previous  message  is: 

Same  as  backing  up 
Same  as  backing  up 

Current  message  is  NN  of  MM  messages  in  file:  <F1LE-NAME> 
Delete  (Message  sequence)  <MSG-SEQUENCE> 

Exec  [confirm] 

Exit  and  update  old  file  <FILE-NAME>  [confirm] 

Forward  (Message  sequence)  <MSG-SEQUENCE> 

Go  to  message  number:  <MES5AGE-NUMBER> 

Headers  (Message  sequence)  <MSG-SEQUENCE> 

Inclusion  of  length  in  header 

Jump  into  lower  fork  running  file:  <Program  Name>  [confirm] 

Koncise  — Provides  shorter  prompting 

List  (Message  sequence)  <MSG-SEQUENCE>  On  file  name: 

<FILE-NAME> 

Move  (Message  sequence)  <MSG-SEQUENCE> 
into  file  name:  <F1LE-NAME> 

Next  message  is: 

(Line  feed)  same  as  next  message  is: 

Overwrite  old  file  <FILE-h'AME>  [confirm] 

Put  (Message  sequence)  <MSG-SEQUENCE> 
into  file  name:  <FILE-NAME> 

Quit  [confirm] 

Read  file  name:  <FILE-NAME> 

SNDMSC  [confirm] 

Type  (Message  sequence)  <MSG-SEQUENCE> 

Undelete  (message  sequence)  <MSG-SEQUENCE> 

Verbose  — Provides  more  prompting 

Write  file  <FILE-NAME>  sorted  by  message  arrival  time 
[confirm] 

Xed  [confirm] 

Zap  profile  [confirm] 

Mark  messages  as  'Examined'  (Message  sequence) 
<MSG-SEQUENCE> 

- Unmark  messages  to  be  NOT  'Examined'  (Message  sequence) 
<MSG-SEQUENCE> 

t (The  time  and  date  is  then  printed) 

T Type  command  character  for  its  description,  ? for  summary 
; Comment  — <Retum>  or  ~Z  returns  you  to  command  level 


.Table  1:  A listing  of  MSC  cob 
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Reduction  S7. 


